<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
 <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.7">
 <TITLE>SDCC Compiler User Guide: Retargetting for other MCUs.</TITLE>
 <LINK HREF="SDCCUdoc-27.html" REL=next>
 <LINK HREF="SDCCUdoc-25.html" REL=previous>
 <LINK HREF="SDCCUdoc.html#toc26" REL=contents>
</HEAD>
<BODY>
<A HREF="SDCCUdoc-27.html">Next</A>
<A HREF="SDCCUdoc-25.html">Previous</A>
<A HREF="SDCCUdoc.html#toc26">Contents</A>
<HR>
<H2><A NAME="Retargetting"></A> <A NAME="s26">26. Retargetting for other MCUs.</A> </H2>

<P>The issues for retargetting the compiler are far too numerous to be covered
by this document. What follows is a brief description of each of the seven
phases of the compiler and its MCU dependency.
<P>
<OL>
<LI>Parsing the source and building the annotated parse tree. This phase is
largely MCU independent (except for the language extensions). Syntax &amp;
semantic checks are also done in this phase , along with some initial optimizations
like back patching labels and the pattern matching optimizations like bit-rotation
etc.</LI>
<LI>The second phase involves generating an intermediate code which can be
easy manipulated during the later phases. This phase is entirely MCU independent.
The intermediate code generation assumes the target machine has unlimited number
of registers, and designates them with the name iTemp. The compiler can be
made to dump a human readable form of the code generated by using the --dumpraw
option.</LI>
<LI>This phase does the bulk of the standard optimizations and is also MCU
independent. This phase can be broken down into several sub-phases.
<UL>
<LI>Break down intermediate code (iCode) into basic blocks.</LI>
<LI>Do control flow &amp; data flow analysis on the basic blocks.</LI>
<LI>Do local common subexpression elimination, then global subexpression elimination</LI>
<LI>dead code elimination</LI>
<LI>loop optimizations</LI>
<LI>if loop optimizations caused any changes then do 'global subexpression
elimination' and 'dead code elimination' again.</LI>
</UL>
</LI>
<LI>This phase determines the live-ranges; by live range I mean those iTemp
variables defined by the compiler that still survive after all the optimizations.
Live range analysis is essential for register allocation, since these computation
determines which of these iTemps will be assigned to registers, and for how
long.</LI>
<LI>Phase five is register allocation. There are two parts to this process
.
<OL>
<LI>The first part I call 'register packing' (for lack of a better term) .
In this case several MCU specific expression folding is done to reduce register
pressure.</LI>
<LI>The second part is more MCU independent and deals with allocating registers
to the remaining live ranges. A lot of MCU specific code does creep into this
phase because of the limited number of index registers available in the 8051.</LI>
</OL>
</LI>
<LI>The Code generation phase is (unhappily), entirely MCU dependent and very
little (if any at all) of this code can be reused for other MCU. However the
scheme for allocating a homogenized assembler operand for each iCode operand
may be reused.</LI>
<LI>As mentioned in the optimization section the peep-hole optimizer is rule
based system, which can reprogrammed for other MCUs.</LI>
</OL>
<HR>
<A HREF="SDCCUdoc-27.html">Next</A>
<A HREF="SDCCUdoc-25.html">Previous</A>
<A HREF="SDCCUdoc.html#toc26">Contents</A>
</BODY>
</HTML>
